platforms/metagram/README.md (1)

38-39: ⚠️ Potential issue

Remove stray backticks and fix formatting.

There's a stray ``` fence at the end of the file that isn't closing any explicit code block. This will render incorrectly in Markdown. Remove the extra backticks and ensure the note about adapters ends with a period:

-> To deploy your app, you may need to install an [adapter](https://svelte.dev/docs/kit/adapters) for your target environment.
-```
+> To deploy your app, you may need to install an [adapter](https://svelte.dev/docs/kit/adapters) for your target environment.

platforms/metagram/project.inlang/cache/plugins/ygx0uiahq6uw (1)

1-17: 🛠️ Refactor suggestion

Minified cache artefact checked into VCS

The file is 1 600+ LOC of minified JS located under project.inlang/cache/….
These files are generated by Inlang and can be recreated at build time; committing them bloats the repo, hinders review, and risks licence issues.

Move the cache directory to .gitignore (or commit the readable TS source + build script instead).

platforms/metagram/project.inlang/cache/plugins/2sy648wh9sugi (4)

1560-1580: ⚠️ Potential issue

Incorrect RegExp – {languageTag|locale} is matched literally, breaking validation

The en schema uses

pattern: ".*\\{languageTag|locale\\}.*\\.json$"

Inside a RegExp, the sequence ...{languageTag|locale}... is interpreted literally (it is not an alternation).
As a result, only the string {languageTag|locale} passes the validation, while the intended {locale} or {languageTag} never match.

-var en = ce.Type.String({
-  pattern: ".*\\{languageTag|locale\\}.*\\.json$",
+var en = ce.Type.String({
+  // allow either {locale} or {languageTag}
+  pattern: ".*\\{(?:languageTag|locale)\\}.*\\.json$",

This bug prevents valid configurations from being accepted at runtime.
Please update the pattern and (if any) adjust the examples/tests.

---

1780-1795: 🛠️ Refactor suggestion

Unnecessary arrow-function indirection when writing JSON

saveMessages contains:

await e.writeFile(
  s["plugin.inlang.messageFormat"].pathPattern.replace("{languageTag}", p),
  (T => JSON.stringify(T, void 0, "	"))({
    $schema: "...",
    ...l
  })
)

Creating an arrow function only to call it immediately harms readability and triggers extra allocations.

await e.writeFile(
-  s["plugin.inlang.messageFormat"].pathPattern.replace("{languageTag}", p),
-  (T => JSON.stringify(T, void 0, "	"))({
-    $schema: "https://inlang.com/schema/inlang-message-format",
-    ...l
-  })
+  s["plugin.inlang.messageFormat"].pathPattern.replace("{languageTag}", p),
+  JSON.stringify(
+    { $schema: "https://inlang.com/schema/inlang-message-format", ...l },
+    null,
+    2        // two-space indent is standard and avoids TAB chars in JSON
+  )
)

This is simpler, faster and easier to debug.

---

1810-1830: 🛠️ Refactor suggestion

Cn() re-implements path.dirname and is OS-sensitive

The custom Cn function attempts to derive a directory path by string/char-code manipulation.
Issues:

1. It assumes forward slashes (/) – will fail on Windows paths containing \.
2. It is difficult to read, test and maintain.
3. Node already provides import { dirname } from "path" which is fully tested and cross-platform.

Recommendation:

- import { /* other imports */, dirname as pathDirname } from "node:path";
...
- const dir = Cn(filePath);
+ const dir = pathDirname(filePath);
...
- function Cn(s) { /* 40 lines of custom logic */ }
+// ‑ remove custom Cn implementation – stdlib is safer

Dropping bespoke path parsing eliminates edge-case bugs and reduces code size.

---

10-40: 🛠️ Refactor suggestion

Huge bundled/minified dependency bloats repository

The file embeds ~3 k lines of minified TypeBox + helper libraries.
Consequences:

• ≈130 KB unminified source committed to VCS
• Difficult to diff, review, debug and track CVEs
• License headers are stripped – may violate upstream license

Prefer installing @sinclair/typebox (and other helpers) via npm and import the needed symbols:

import { Type, Static } from "@sinclair/typebox";

This keeps the plugin tree-shakeable, clearer, and ensures you receive upstream security fixes.

platforms/metagram/README.md (3)

1-4: Refine the title and description for clarity.

The current heading # sv is too generic and doesn't reflect that this README is for the Metagram project. Consider updating it to:

# Metagram
A SvelteKit-based application setup powered by the `sv` CLI.

This will make the purpose immediately clear for developers.

---

5-15: Clarify prerequisites and command context.

The "Creating a project" instructions assume sv is available via npx, but it may help to note that the CLI is installed as part of this setup or provide a link to installation instructions. Also, specify that these commands should be run from the directory where you want the app. For example:

Before running the commands below, ensure you're in an empty directory or specify the target folder.

---

29-36: Building & preview section is clear.

The steps to build and preview the project are accurate. Consider adding a brief note on cleaning the build output if necessary (e.g., when switching branches).

platforms/metagram/src/stories/button.css (1)

1-30: Accessibility enhancements: add focus styles & verify contrast.

• Add a visible focus indicator for keyboard users:

  .storybook-button:focus-visible {
    outline: 2px solid #555ab9;
    outline-offset: 2px;
  }

• Confirm that the primary color #555ab9 on white meets WCAG AA contrast (4.5:1). If not, consider darkening the shade or adjusting text color.

platforms/metagram/project.inlang/project_id (1)

1-1: Add a trailing newline for POSIX compliance.

Ensure there is a newline at the end of this file to avoid issues with POSIX tools and diff utilities.

platforms/metagram/src/routes/demo/+page.svelte (1)

1-1: Consider adding SvelteKit prefetch for smoother navigation
You may optionally enhance UX by prefetching the demo route:

<a sveltekit:prefetch href="/demo/paraglide">Paraglide demo</a>

platforms/metagram/src/routes/+page.svelte (1)

1-2: Customize the landing page for Metagram branding
The default SvelteKit welcome text is fine for initial scaffolding but consider renaming to something like “Welcome to Metagram” and adding rel="noopener noreferrer" on external links:

-<h1>Welcome to SvelteKit</h1>
+<h1>Welcome to Metagram</h1>
-<p>Visit <a href="https://svelte.dev/docs/kit">svelte.dev/docs/kit</a> to read the documentation</p>
+<p>Visit <a href="https://svelte.dev/docs/kit" rel="noopener noreferrer">SvelteKit docs</a> for more details</p>

platforms/metagram/messages/es.json (1)

3-3: Improve Spanish translation.
The "hello_world" entry currently contains an English string. Consider providing a proper Spanish translation, for example "¡Hola, {name}!", to ensure meaningful localization.

platforms/metagram/src/hooks.ts (2)

3-3: Add explicit TypeScript types to reroute.
Declare the request parameter type (e.g., RequestEvent from @sveltejs/kit) and specify the return type string. This enhances type safety and IDE support.

---

1-3: Ensure reroute has unit test coverage.
No tests currently exercise this function. Consider adding unit tests for URL normalization and edge cases (e.g., missing locale segments) to validate the behavior.

platforms/metagram/src/stories/header.css (1)

1-33: Consider using Tailwind instead of traditional CSS.

Since the project uses Tailwind CSS (as configured in vite.config.ts), consider refactoring this CSS to use Tailwind utility classes for consistency. This would align with the project's styling approach and reduce maintenance overhead.

Additionally, the header styling doesn't appear to include responsive design considerations.

You could refactor the component to use Tailwind instead:

- .storybook-header {
-   display: flex;
-   justify-content: space-between;
-   align-items: center;
-   border-bottom: 1px solid rgba(0, 0, 0, 0.1);
-   padding: 15px 20px;
-   font-family: 'Nunito Sans', 'Helvetica Neue', Helvetica, Arial, sans-serif;
- }

And then in the component:

<header class="flex justify-between items-center border-b border-black/10 p-[15px_20px] font-['Nunito_Sans',_'Helvetica_Neue',_Helvetica,_Arial,_sans-serif]">
  <!-- Header content -->
</header>

platforms/metagram/src/hooks.server.ts (2)

4-10: Add error handling to the middleware integration.

The current implementation doesn't handle potential errors from the Paraglide middleware. Consider adding try/catch blocks to provide graceful fallbacks if the middleware fails.

-const handleParaglide: Handle = ({ event, resolve }) => paraglideMiddleware(event.request, ({ request, locale }) => {
+const handleParaglide: Handle = async ({ event, resolve }) => {
+  try {
+    return await paraglideMiddleware(event.request, ({ request, locale }) => {
+      event.request = request;
+
+      return resolve(event, {
+        transformPageChunk: ({ html }) => html.replace('%paraglide.lang%', locale)
+      });
+    });
+  } catch (error) {
+    console.error('Paraglide middleware error:', error);
+    // Fallback to default locale
+    return resolve(event, {
+      transformPageChunk: ({ html }) => html.replace('%paraglide.lang%', 'en')
+    });
+  }
+};

---

4-12: Consider using SvelteKit's sequence helper for future middleware additions.

If you plan to add more middleware in the future, refactor this to use SvelteKit's sequence helper to chain multiple handle functions.

+import { sequence } from '@sveltejs/kit/hooks';

 const handleParaglide: Handle = ({ event, resolve }) => paraglideMiddleware(event.request, ({ request, locale }) => {
 	event.request = request;

 	return resolve(event, {
 		transformPageChunk: ({ html }) => html.replace('%paraglide.lang%', locale)
 	});
 });

-export const handle: Handle = handleParaglide;
+// Future middleware can be added like this:
+// const handleSomethingElse: Handle = async ({ event, resolve }) => {
+//   // Do something with the event
+//   return resolve(event);
+// };
+
+export const handle: Handle = handleParaglide;
+// When you need multiple middleware:
+// export const handle = sequence(handleParaglide, handleSomethingElse);

platforms/metagram/src/routes/demo/paraglide/+page.svelte (1)

11-14: Convert HTML onclick to Svelte event directives

Consider using Svelte's event directive syntax instead of HTML onclick attributes for better consistency with Svelte conventions.

<div>
-	<button onclick={() => setLocale('en')}>en</button>
-	<button onclick={() => setLocale('es')}>es</button>
+	<button on:click={() => setLocale('en')}>en</button>
+	<button on:click={() => setLocale('es')}>es</button>
</div>

platforms/metagram/.storybook/main.ts (2)

3-4: Use Node.js protocol for built-in modules

Update the path import to use the node: protocol for better explicitness.

-import { join, dirname } from "path"
+import { join, dirname } from "node:path"

🧰 Tools

🪛 Biome (1.9.4)

[error] 3-3: A Node.js builtin module should be imported with the node: protocol.

Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.

(lint/style/useNodejsImportProtocol)

---

9-11: Replace 'any' with a more specific return type

Using 'any' disables type checking. Specify a more precise return type for better type safety.

-function getAbsolutePath(value: string): any {
+function getAbsolutePath(value: string): string {
  return dirname(require.resolve(join(value, 'package.json')))
}

🧰 Tools

🪛 Biome (1.9.4)

[error] 9-9: Unexpected any. Specify a different type.

any disables many type checking rules. Its use should be avoided.

(lint/suspicious/noExplicitAny)

platforms/metagram/package.json (1)

10-12: Consider simplifying the prepare script.

The || echo '' suppresses errors from svelte-kit sync. It might hide real issues during install. Consider handling failures explicitly or removing the fallback for clearer diagnostics.

platforms/metagram/tsconfig.json (2)

2-13: Explicitly include project files in tsconfig.

To avoid accidentally type-checking build artifacts or irrelevant directories, you may want to add an include (e.g., "src/**/*", "project.inlang/**/*") at the root level. This makes your project boundaries explicit.

---

14-19: Move comments inside the JSONC object.

While tsconfig.json supports comments, placing them outside the closing brace may confuse some tools. Consider moving these inline comments into the root object (or under a dedicated documentation key) for maintainability.

platforms/metagram/src/app.html (2)

1-8: Add a default <title> tag.

Right now, the template relies on child pages to inject <title>. Consider adding a fallback title inside <head> (e.g., <title>Metagram</title>) so the app has a meaningful title even if a page doesn’t declare one.

---

9-10: Extract inline styles to CSS.

The style="display: contents" on the wrapper <div> could be moved into a global CSS or a utility class for better separation of concerns and easier theming.

platforms/metagram/src/stories/Header.svelte (1)

5-12: Consider adding null checks for callback handlers

The component doesn't check if the callback handlers exist before using them. Consider adding optional chaining when calling these functions to prevent potential runtime errors.

-<Button size="small" onClick={onLogout} label="Log out" />
+<Button size="small" onClick={() => onLogout?.()} label="Log out" />

-<Button size="small" onClick={onLogin} label="Log in" />
+<Button size="small" onClick={() => onLogin?.()} label="Log in" />

-<Button primary size="small" onClick={onCreateAccount} label="Sign up" />
+<Button primary size="small" onClick={() => onCreateAccount?.()} label="Sign up" />

platforms/metagram/src/stories/Page.svelte (2)

10-14: Duplicate handler logic could be refactored

The onLogin and onCreateAccount handlers perform identical actions. Consider refactoring to reuse the same handler for both events to improve maintainability.

<Header
  {user}
-  onLogin={() => (user = { name: 'Jane Doe' })}
+  onLogin={setUser}
  onLogout={() => (user = undefined)}
-  onCreateAccount={() => (user = { name: 'Jane Doe' })}
+  onCreateAccount={setUser}
/>

+<script lang="ts">
+  // Add this function to the script section
+  function setUser() {
+    user = { name: 'Jane Doe' };
+  }
+</script>

---

56-66: SVG path data formatting issues

The SVG path data is split across multiple lines with trailing spaces, which might cause rendering issues in some browsers. Consider using a continuous string without line breaks or trailing spaces.

-        <path
-            d="M1.5 5.2h4.8c.3 0 .5.2.5.4v5.1c-.1.2-.3.3-.4.3H1.4a.5.5 0
-            01-.5-.4V5.7c0-.3.2-.5.5-.5zm0-2.1h6.9c.3 0 .5.2.5.4v7a.5.5 0 01-1 0V4H1.5a.5.5 0
-            010-1zm0-2.1h9c.3 0 .5.2.5.4v9.1a.5.5 0 01-1 0V2H1.5a.5.5 0 010-1zm4.3 5.2H2V10h3.8V6.2z"
-            id="a"
-            fill="#999"
-          />
+        <path
+            d="M1.5 5.2h4.8c.3 0 .5.2.5.4v5.1c-.1.2-.3.3-.4.3H1.4a.5.5 0 01-.5-.4V5.7c0-.3.2-.5.5-.5zm0-2.1h6.9c.3 0 .5.2.5.4v7a.5.5 0 01-1 0V4H1.5a.5.5 0 010-1zm0-2.1h9c.3 0 .5.2.5.4v9.1a.5.5 0 01-1 0V2H1.5a.5.5 0 010-1zm4.3 5.2H2V10h3.8V6.2z"
+            id="a"
+            fill="#999"
+          />

platforms/metagram/project.inlang/cache/plugins/2sy648wh9sugi (1)

1850-1870: Plugin emits console.log during migration – side-effect in library code

$n() logs directly to stdout:

console.log("Migration to v2 ...")

Logging from within a plugin library couples it to the host environment and may pollute CI outputs.
Instead, expose the migration result to the caller or inject a logger:

- console.log("Migration to v2 of the inlang-message-format plugin was successful. ...")
+ if (typeof settings.logger === "function") {
+     settings.logger(
+         "info",
+         "Migration to v2 of the inlang-message-format plugin was successful. Please delete ..."
+     );
+ }

At minimum, guard behind process.env.NODE_ENV !== "test" or provide a verbose flag.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

platforms/metagram/src/routes/+page.svelte (3)

1-1: This is a good start, but consider enhancing the main page with more content.

The heading clearly identifies the application, but as the main landing page for Metagram, it would benefit from additional content to provide context and guide users.

Consider expanding this page with:

-<h1 class="text-5xl text-red-500">Metagram</h1>
+<section class="container mx-auto p-4">
+  <h1 class="text-5xl font-bold mb-4">Metagram</h1>
+  <p class="text-xl mb-6">A platform for connecting and sharing with others</p>
+  <!-- Add call-to-action buttons or feature highlights here -->
+</section>

---

1-1: Review color choice for branding consistency.

The bright red color (text-red-500) may be a placeholder. Ensure this aligns with your application's design system and branding guidelines.

If this is just a placeholder, consider using your brand's primary color:

-<h1 class="text-5xl text-red-500">Metagram</h1>
+<h1 class="text-5xl text-primary">Metagram</h1>

---

1-1: Add SEO-friendly metadata for the page.

For better search engine optimization and social media sharing, consider adding metadata to this main page.

You can add a <svelte:head> element with appropriate metadata:

+<svelte:head>
+  <title>Metagram - Connect and Share</title>
+  <meta name="description" content="Metagram is a platform for connecting and sharing with others" />
+</svelte:head>
+
<h1 class="text-5xl text-red-500">Metagram</h1>

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

platforms/metagram/src/routes/+page.svelte (1)

1-6: Consider implementing internationalization for text content.

Since the project includes i18n setup with @inlang/paraglide-js as mentioned in the summary, text content should leverage the translation framework rather than using hardcoded strings.

-<h1>metagram</h1>
-<h2>metagram</h2>
-<h3>metagram</h3>
-<p>metagram</p>
-<p class="small">metagram</p>
-<p class="subtext">metagram</p>
+<script>
+  import { t } from '../i18n';
+</script>
+
+<h1>{t('app.title')}</h1>
+<h2>{t('app.subtitle')}</h2>
+<h3>{t('app.section_title')}</h3>
+<p>{t('app.description')}</p>
+<p class="small">{t('app.additional_info')}</p>
+<p class="subtext">{t('app.disclaimer')}</p>

platforms/metagram/src/routes/+page.svelte (2)

1-6: Add documentation and structural organization.

As this is the main landing page for the Metagram platform, consider adding component documentation and proper structural organization following SvelteKit best practices.

+<script>
+  // Main landing page for Metagram platform
+  // Displays welcome content and introductory information
+</script>
+
+<svelte:head>
+  <title>Metagram - Share your moments</title>
+  <meta name="description" content="Connect and share with your community on Metagram" />
+</svelte:head>
+
+<section aria-labelledby="main-heading">
+  <h1 id="main-heading">metagram</h1>
+  <h2>metagram</h2>
+  <h3>metagram</h3>
+  <p>metagram</p>
+  <p class="small">metagram</p>
+  <p class="subtext">metagram</p>
+</section>

---

1-6: Consider adding Tailwind CSS classes.

According to the summary, the project uses Tailwind CSS. Consider utilizing Tailwind classes for styling instead of relying solely on custom CSS classes.

-<h1>metagram</h1>
-<h2>metagram</h2>
-<h3>metagram</h3>
-<p>metagram</p>
-<p class="small">metagram</p>
-<p class="subtext">metagram</p>
+<h1 class="text-4xl font-bold text-primary mb-4">metagram</h1>
+<h2 class="text-2xl font-semibold text-secondary mb-3">metagram</h2>
+<h3 class="text-xl font-medium mb-2">metagram</h3>
+<p class="text-base mb-4">metagram</p>
+<p class="text-sm mb-2 small">metagram</p>
+<p class="text-xs text-gray-500 subtext">metagram</p>

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

platforms/metagram/src/lib/types.ts (1)

1-1: Use import type for type-only imports

Since SVGAttributes is only used as a type, it's better to use import type to ensure the import is removed during compilation, which can help with tree-shaking.

-import { type SVGAttributes } from 'svelte/elements';
+import type { SVGAttributes } from 'svelte/elements';

🧰 Tools

🪛 Biome (1.9.4)

[error] 1-1: All these imports are only used as types.

Importing the types with import type ensures that they are removed by the compilers and avoids loading unnecessary modules.
Safe fix: Use import type.

(lint/style/useImportType)

platforms/metagram/.storybook/main.ts (2)

3-3: Use node: protocol for Node.js built-in modules

For better clarity and to follow modern best practices, Node.js built-in modules should be imported with the node: protocol prefix.

-import { join, dirname } from 'path';
+import { join, dirname } from 'node:path';

🧰 Tools

🪛 Biome (1.9.4)

[error] 3-3: A Node.js builtin module should be imported with the node: protocol.

Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.

(lint/style/useNodejsImportProtocol)

---

9-11: Avoid using any type

The any type disables TypeScript's type checking. Consider using a more specific return type for better type safety.

-function getAbsolutePath(value: string): any {
+function getAbsolutePath(value: string): string {
 	return dirname(require.resolve(join(value, 'package.json')));
}

🧰 Tools

🪛 Biome (1.9.4)

[error] 9-9: Unexpected any. Specify a different type.

any disables many type checking rules. Its use should be avoided.

(lint/suspicious/noExplicitAny)

platforms/metagram/src/lib/icons/Icons.stories.ts (1)

8-8: Avoid using any type

Using any disables TypeScript's type checking. Consider using a more specific type for the Storybook args parameter.

-	render: (args: any) => ({
+	render: (args: Record<string, unknown>) => ({

Alternatively, if you know the specific props that the Icons component accepts, you could create a proper type for it:

type IconsProps = {
  // Define props here
};

// Then use it
render: (args: IconsProps) => ({

🧰 Tools

🪛 Biome (1.9.4)

[error] 8-8: Unexpected any. Specify a different type.

any disables many type checking rules. Its use should be avoided.

(lint/suspicious/noExplicitAny)

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

platforms/metagram/.storybook/main.ts (2)

3-3: Update Node.js import to use the node: protocol

Import Node.js built-in modules with the node: protocol to explicitly indicate that these are Node.js core modules. This improves code clarity and future compatibility.

- import { join, dirname } from 'path';
+ import { join, dirname } from 'node:path';

🧰 Tools

🪛 Biome (1.9.4)

[error] 3-3: A Node.js builtin module should be imported with the node: protocol.

Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.

(lint/style/useNodejsImportProtocol)

---

12-23: Consider additional Storybook addons for improved development experience

The current Storybook configuration includes essential addons, but you might benefit from adding a few more commonly used ones:

addons: [
  getAbsolutePath('@storybook/addon-essentials'),
  getAbsolutePath('@storybook/addon-svelte-csf'),
  getAbsolutePath('@chromatic-com/storybook'),
+ getAbsolutePath('@storybook/addon-a11y'),
+ getAbsolutePath('@storybook/addon-viewport'),
],

The addon-a11y will help catch accessibility issues during development, while addon-viewport provides responsive design testing capabilities.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

platforms/metagram/src/app.css (1)

32-53: 🛠️ Refactor suggestion

⚠️ Potential issue

Critical: Replace non-standard @theme rule with :root for CSS variables
The @theme at-rule isn’t recognized by browsers or Tailwind by default. Move your CSS custom properties into a :root selector so they’re available at runtime:

-@theme {
-  /* fonts */
-  --font-geist: 'Geist', sans-serif;
-
-  /* colors */
-  --color-black: #1f1f1f;
-  --color-black-800: #4c4c4c;
-  /* …other vars… */
-  --color-brand-gradient: linear-gradient(
-    91.82deg,
-    #4d44ef -36.17%,
-    #f35b5b 57.95%,
-    #f7a428 152.07%
-  );
-}
+:root {
+  /* fonts */
+  --font-geist: 'Geist', sans-serif;
+
+  /* colors */
+  --color-black: #1f1f1f;
+  --color-black-800: #4c4c4c;
+  /* …other vars… */
+  --color-brand-gradient: linear-gradient(
+    91.82deg,
+    #4d44ef -36.17%,
+    #f35b5b 57.95%,
+    #f7a428 152.07%
+  );
+}

This ensures the variables are applied globally.

platforms/metagram/src/app.css (1)

1-1: Use official Tailwind directives instead of a generic import
The @import 'tailwindcss'; directive may not correctly apply Tailwind’s layers. Replace it with the official layer directives:

@tailwind base;
@tailwind components;
@tailwind utilities;

Or, if importing a pre-built bundle, point to tailwindcss/tailwind.css instead.

platforms/metagram/src/app.css (1)

3-9: Include additional font formats and verify asset path
We only declare a TTF font; consider adding WOFF2/WOFF for broader browser support. Also ensure the file lives in static/fonts/ so the /fonts/… URL resolves correctly. For example:

 @font-face {
   font-family: 'Geist', sans-serif;
   font-style: normal;
   font-weight: 700;
   font-display: swap;
-  src: url('/fonts/Geist-VariableFont_wght.ttf') format('truetype');
+  src: url('/fonts/Geist-VariableFont_wght.woff2') format('woff2'),
+       url('/fonts/Geist-VariableFont_wght.woff') format('woff'),
+       url('/fonts/Geist-VariableFont_wght.ttf') format('truetype');
 }

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

platforms/metagram/src/lib/ui/Button/Button.stories.ts (1)

1-35: LGTM! Consider adding stories for additional button states.

The Storybook stories for the Button component are well-structured and demonstrate key functionality. The implementation follows best practices with proper typing and demonstrates various button states effectively.

Consider adding stories for:

1. Disabled state - to demonstrate how the button appears when disabled
2. White variant - this variant is defined in the Button component but doesn't have a corresponding story

+export const Disabled = {
+	args: { disabled: true, children: ButtonText }
+};
+
+export const White = {
+	args: { variant: 'white', children: ButtonText }
+};

platforms/metagram/src/lib/ui/Button/Button.svelte (2)

89-98: Consider refining the loading state UI.

The current implementation adds a loading spinner but only blurs the button text. This approach might cause issues:

1. The blur effect (blur-xs) may not be visually obvious enough
2. The spinner is always white (text-white), which might not contrast well with all button variants

Consider these improvements:

       <div
           class="flex items-center justify-center duration-100"
-          class:blur-xs={isLoading || isSubmitting}
+          class:opacity-50={isLoading || isSubmitting}
       >
           {@render children?.()}
       </div>
       {#if isLoading || isSubmitting}
-          <div class="loading loading-spinner loading-xl absolute text-white"></div>
+          <div class="loading loading-spinner loading-xl absolute" class:text-white={variant !== 'white'}></div>
       {/if}

---

76-83: Simplify class joining with the cn utility.

The current implementation uses both cn() and .join(' '), which is redundant since the cn utility likely already handles joining classes with spaces.

	class={cn(
-		[
-			classes.common,
-			classes.background,
-			classes.text,
-			disabled && classes.disabled,
-			restProps.class
-		].join(' ')
+		classes.common,
+		classes.background,
+		classes.text,
+		disabled && classes.disabled,
+		restProps.class
	)}

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro